The current IT security landscape is dreary. Today, security threats are rapidly increasing. New variants of malware are continuously being developed and distributed. It is estimated that more malware has been developed on the last sixth months alone than on the rest of the computer science history.
Currently all aspects of the network experience are affected by security threats, from the quality of experience, to the network infrastructure. According to the latest ‘Study on Information security and e-trust on Spanish Households’, about 44% of users consider security a main limitation to restrict use of new services.
One of the main problems that commercial systems face today is identity theft. By supplanting a customer, a criminal might cause harm to the customer, the system, the system provider's reputation, or all of them. For example, if a bank customer has the identity of some customers stolen, its customers will suffer financial loss in the first stage. But the financial loss can possibly be transferred to the bank, depending on the legislation, and in any case the bank's reputation will suffer even if it wasn't its fault to begin with.
One of the easiest and main methods for a criminal to acquire a legitimate customer identity is by phishing. Phishing is a way of attempting to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication. An example of phishing is a false mail from a bank stating that its customers have to go to some page and introduce their usernames and passwords.
Phishing attacks against banks started in 2003, with half a dozen attempts reported. The early attacks imitated bank websites, but were both crude and greedy. Since then the attacks have become more sophisticated. They often reuse genuine bank emails, just changing the URLS, for example.
Losses are growing extremely rapidly, with maybe $200 m in the USA in 2006, and $70 m in the UK. And Phishing is not restricted to banks anymore. Any online activity that has an associated economic value is a potential target. Thus, in the last years there have been attacks against targets as diverse as online gaming sites, email providers, payment processors, online auction sites, online shops, etc.
Some of the current client side solutions against phishing are detailed below:
Password Manglers: A password mangler is a piece of software, generally a browser plug-in that runs on the customer's device that modifies the password that the user enters for each URL. Thus, if the user enters as password ‘abcd1234’ for two different sites, the password that will actually be sent to the sites will be different for each, and different from the seed password ‘abcd1234’. Thus, even if the user is fooled into visiting a phishing site, since the phishing site's URL will be different from the legitimate one, the password that will be sent will also be different (and useless to the phisher).
The problem with passwords manglers is that work fine in theory but are tricky to implement in practice, since there are some problems to implement them, such as:                Sites with different domains that share the passwords (such as amazon.com, amazon.co.uk) are a problem.        The automatically generated passwords might break some sites password rules.        The software must be already be in use when registering in a new site.        Some bank sites don't allow users to choose their own passwords.        Roaming is difficult for customers: they cannot just use another computer or device.        They don't protect against keyloggers at all.        It depends on the customer's discipline: customers have to install and maintain the password mangler software.        
Client Certificates: SSL protocol supports certificates for the client as well as the server. Thus, a certificate could be used to identify the customer instead of a password. Since certificates can also be stolen if stored in software (and almost the same phishing methods would be valid to steal the certificate than the password), hardware stored certificates (such as the DNIe) could be used to identify users.
The problem is that client certificates stored on software do not add any actual protection against identity theft, since the criminals can ask for the key storage file instead of the user's password. Client certificates stored on hardware are an effective mechanism against some kinds of identity theft, but they require non standard hardware on the customer's device, and will not work on many of the current mobile devices.
Using the Browser's Password Database: Another line of defence could be choosing random passwords and letting the browser store them. This method is similar to the password mangler, since its main line of defence is that the browser will auto complete passwords based on the site domain, and thus it will not auto complete the password on the phishing's site.
This solution can be effective, but it will not protect against malware that just steals the password database, and it make user's roaming difficult. Besides, users will have to re-introduce the passwords on the databases of any mobile devices they use.
Soft Keyboards: This method consists in forcing the user to fill in the password using an in-screen keyboard and clicking on the images of the letters instead of typing them. It is mainly meant to defeat keyloggers.
The problem is that there currently exists software to defeat this protection. For example, the software can capture the screen for any number of pixels around each mouse click and send the images to the phisher so he can obtain the password.
Customer Education: Another line of defence is training customers into detecting the false sites, and to not install any suspicious applications on their computers. If the customers do not visit the phishing site and they do not install malware on their computer, then the phishing problem would go away.
However, this is an unending arms race. The legitimate sites tell the customers to search for some characteristic of the fake messages, so the phishers modify the messages and the process starts again. As the countermeasures grow they become no complex and counterintuitive that they confuse more and more customers, and at the end it works in favour of the attackers.
Besides the client-side solutions, there is a reactive defence mechanism for some sites on the server side/management side, such as banks. The reactive mechanism is to monitor the net trying to detect phishing sites. Once a phishing site is detected, the legitimate site will take measures to take down the phishing site (such as talking to their DNS provider to remove the phishing site DNS record, or talking to their ISP to take their site down). These reactive defence mechanisms work to limit the damage done on each attack (by closing the fake sites as soon as possible), but they do not eliminate the problem and they do nothing to identify customers that might have been affected before the fake site takedown.
Besides those mitigation measures, there are other measures based on injecting false data on the criminals (phishers) databases. Patent document US-2007/0107053-A1 describes a system to identify phishing sites and propagate a previously generated database of false data to them. Some items of the false data can be provided by the third party service provider, and will allow the third party service provider to evaluate the success of the poisoning. The problem with this solution is that it requires the false data to be previously provided. This restricts the dilution—defined as the ratio of false to real data—on the fake credentials database since the maximum dilution will depend on the false data database size. More importantly, only some of the false data is used to identify fraudulent access, and there is no way to identify legitimate users affected.
Also, patent document WO 2009/055785-A2 describes a system to be implemented on service provider systems—particularly banks—that based on a pre-generated database of false identifying data allows the detection of access to the false accounts, and the tracking of the actions executed by the criminals on the system, This solution also requires some false data to be previously provided, with a set of restrictions that severely limits the maximum practical size of the false data set. It allows the identification of an affected legitimate user, but with two important problems that make it ineffective:
Since the maximum dilution will be very small—caused by the limited size of the false data set—the effectiveness will be severely hampered. Only a small subset of the affected legitimate users will be detected.
More importantly, the detection is made after the fact—after the legitimate user account has been accessed and potentially the fraud has been committed.
All the existing antifraud or phishing mitigating measures try to avoid that customers of a service provide their credentials to a criminal network (phishers). But there is no bullet proof measure against phishing, and as such, every year thousands of accounts are compromised. Currently there are no methods to identify identity theft fraud before the fraud (be it read mail, distribute spam, or plain theft in case of bank credentials) has been committed. Some of the solutions allow the detection of the fraud, but after the fraud has been committed—and after the economic loss has happened. So the problem remains: how to detect identity theft before the actual harm—fraud—has been committed.
The authentication systems allow restricting access to web services, so that only those users with valid credentials are allowed to login. The basic authentication systems, which are most commonly used, are based on a previous registration process for the user to define its digital identity as a username and password. For users who have been victims of phishing, someone with this information because he has “stolen” it, could enter the system without being detected, as the basic authentication is based simply on knowing username/password. Although there are other safer authentication systems, the technical problem the invention seeks to address is how to prevent this “someone” who has “stolen” credentials from accessing the system (login), despite the fact that he knows the valid user name/password. Because basic authentication is based on knowing the user credentials—essentially username/password—, it is not known a priori (before the user reports the theft) whether a connection is legitimate or if a victim of phishing.